 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
(crossposted from povray.general - "The Language of POV" thread)
If you've got an itching, an interest, or a burning desire
for XML based POV data storage, speak now. Please don't
recycle the flames from the previous thread... :-)
What I would like to do is develop a proposal - do more
conceptual development, demonstrate more advantages,
consider the implications for the Povray architecture.
Ken Tyler on the idea of XML for Povray:
> > If there are other people who find these
> > possibilities attractive, I would be interested
> > in developing a more detailed proposal. Some
> > aspects would require interaction with the
> > POV team, or the TAG people - but I think it's
> > fair to present them with more than a
> > "we think XML is funky idea" or have them
> > sift through threads of conceptual development
> > and hysterical backlash.
>
> Speaking as a TAG member I will offer this advice. If you can get other
> people excited about your ideas, and between you draft a concrete proposal,
> I would be happy to present it to the POV-Team on your behalf for their
> consideration. It would really help if you could figure out a way to make
> all of us understand the ramifications of your proposal, and get us excited
> about it, but if you are sure it has merit I/we will not stand in your way.
>
> What you need to bring to the table -
>
> 1. Detail your proposal as far as functionality and purpose.
>
> 2. Describe in detail what advantages your proposal has over the current
> system.
>
> 3. Who benefits from the changes or additions of your proposal.
>
> 4. Try to give some indication of how difficult it will be to implement
> and what kind of language support will be needed to make it portable
> to all platforms that POV-Ray currently supports.
>
> Remember that if you cannont get other people here excited about your
> proposal there is little likelihood the POV-Team will get excited about
> it. Also remember that timing may be everything. Right now the POV-Team
> is actively working on finalizing the release of POV-Ray v3.5 which for
> all intents and purposes should be considered feature locked at this time.
> This means from the POV-Team's point of view any action they might take
> towards your proposal will have to wait for their planned C++ re-write
> for POV-Ray v4.0. As far as I know the POV-Team has not entered into
> any detailed discussions on what changes will be made in v4.0, other
> than the move to C++, and it is likely they will want to have their own
> data structure decided before accepting additional suggestions in this
> regard. Their internal discussions will likely be sometime down the
> road when the release of POV-Ray v3.5 has been made public and they have
> had a chance to hammer the public reported bugs out of it.
>
> Keep this in mind...
>
> What you are proposing may actually be better suited for a dedicated
> patch of the program rather than something the mainstream POV-Ray user
> will be interested in having in the official version of the program.
The previous post:
> So what exactly are you suggesting? That POV should use XML for data
> representation and should internally convert POV-Script to XML as well
> as supporting XML input?
I've been giving this some thought today, pondering the
technicalities as well the unexpected hysteria generated
on povray.general and the IMP list. Every day I go to
work improving a software product, trying to deliver the
features that users are asking for. I get a lot of
satisfaction from finding elegant, robust and user
friendly solutions to new problems. But, in the context
of povray, the mere suggestion of some kind of paradigm
shift seems to upset people very quickly.
Anyway - here is a more concrete model of how I think
povray data input should be handled. There needs to
be a clean and simple interface between the POV parser
implementation and the core POVray raytracing engine.
This API might look like a bunch of simple functions
such as "bool insertSphere(...)" which is as minimal
as possible, while supporting all of the POV data types.
Things like loops, variables and macros should be
strictly layered above this API. This API would also
make a nice DLL interface, eventhough the POVteam
don't like the idea of POV being used as a library.
The existing parser simply becomes one possible user
of this API. Text editing die-hards can do whatever
they please, without any threat from trendy programmer
types who want to do different things. Another user
of this API could be an interpreted C environment,
POV-CSDL, XML, or whatever takes people's fancy.
The POV-team control the "official" API, but allow
people to build on top of it freely. Ideally, the
API is also made available as DLL so that Java, C,
Delphi, etc programmers can do whatever they like,
in the language of their choice.
This handles input. Another question is output -
would it be useful and desirable to provide some
mechanism to extract the state of a POV world
at runtime? Maybe, maybe not. I do not intend
to deal with this at this stage.
Before closing, a few points about an XML pov
that perhaps have not been stated clearly:
XML is certainly not customised for the problem
of text editing descriptions of 3D scenes. It's
not bad, but it's not ideal.
XML is a mechanism that would allow third party
tools to manipulate POV scenes. You load the
data in, edit geometry, textures, etc, then
save the data out. One critical limitation in
POV script is the difficulty in parsing it.
In some ways, POV script has been so heavily
optimised for hand editing (in addition to
the macro and looping constructs) that it
is much more complicated than it needs to be
for many other tasks.
XML is a mechanism that simplifies extension.
You don't need to be a parser expert to define
new data types, or to add attributes to objects.
Because the grammar is less ambigous (taking
advantage of verbosity) an XML parser can
ignore irrelevant data - but preserve it.
Backwards compatibilty in a scheme like POV
script is a more difficult problem.
XML allows POV to take advantage of related
technology such as VRML. To support VRML
datatypes, we simply borrow the grammar -
no parser programming necessary. To support
a new procedural texturing architecture, we
borrow their grammar, no parser programming
necessary. (There is a big difference between
writing a parser and writing handlers for
an XML parser)
If there are other people who find these
possibilities attractive, I would be interested
in developing a more detailed proposal. Some
aspects would require interaction with the
POV team, or the TAG people - but I think it's
fair to present them with more than a
"we think XML is funky idea" or have them
sift through threads of conceptual development
and hysterical backlash.
XML is of immediate commercial interest to me
for other projects, so I can justify a lot of
time as developing expertise. ("homework")
I think that there should be at least a
group of people involved, and a healthy
discussion, in combination with some
public relations. If you think that XML
is an interesting technology to apply to
POVray, are just curious about XML, I would
encourage you to drop me an email.
XML does not mean manual editing of tags
in a text editor. People that keep harping
on this are just being silly. But I am quite
convinced that text editing should become a
thing of the past. (I never can remember
the RGB or even name for "that favorite
blueish grey" that I always like to use, nor
should I have to remember junk like that.)
--
Nigel Stewart (nig### [at] nigels com)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Check out http://www.xml.org/xmlorg_registry/index.shtml
for a nice long list of XML based data definition projects.
POV should be in this list too.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 15 Mar 2000 00:14:02 +1100, Nigel Stewart <nig### [at] nigelscom>
wrote:
>(crossposted from povray.general - "The Language of POV" thread)
>
>If you've got an itching, an interest, or a burning desire
>for XML based POV data storage, speak now. Please don't
>recycle the flames from the previous thread... :-)
>What I would like to do is develop a proposal - do more
>conceptual development, demonstrate more advantages,
>consider the implications for the Povray architecture.
I would certainly like to see what could be done with XML.
Unfortunately, I am not really a programmer. If there is anything I
can help with, I will. I just don't know how much help I will be.
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote in message <38C### [at] nigelscom>...
> Anyway - here is a more concrete model of how I think
> povray data input should be handled. There needs to
> be a clean and simple interface between the POV parser
> implementation and the core POVray raytracing engine.
> This API might look like a bunch of simple functions
> such as "bool insertSphere(...)" which is as minimal
> as possible, while supporting all of the POV data types.
> Things like loops, variables and macros should be
> strictly layered above this API.
I'm not particularly interested in an XML POV-script. However, completely
separating the parser from the renderer to allow other languages to be used
for writing POV scenes without going through the intermediary of POV-Script
sounds like an excellent idea.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm not particularly interested in an XML POV-script. However, completely
> separating the parser from the renderer to allow other languages to be used
> for writing POV scenes without going through the intermediary of POV-Script
> sounds like an excellent idea.
And an idea that I hope the POV team will consider revisiting.
They have taken the position that POV shall not be used as
a library, but I really do think it's worth reconsidering this
position - at least from a technical point of view.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
(Crossposted from private email to Ken, with permission)
> I do not personally like the example you gave and think
> it unnecessarily makes the scene language harder to use and
> understand.
I'm working on the assumption that hand-editing is
not the only way to describe a 3D scene. XML I think
is editable, but certainly not optimised for this task.
It is however, far more generic and flexible. XML would
never be a replacement for POV script, only an alternative.
> And correct me if I am wrong but isn't HTML just a glorified text based
> word processing and illustration language designed exclusively for 2d
> work?
HTML began as a mark-up language for ASCII. The idea was
to encode the structure of the document (headings, titles,
paragraphs, lists) into the document, and let the browser
decide how to format the result. This is not a new idea,
LaTeX does a similar thing, a document processing system
that to me is similar to XML in its reasoning.
Then, when the World Wide Web became mainstream, HTML got
polluted with tags that control the appearence of the page -
fonts and colours, table style, buttons, etc.
HTML is being evolved to XML in the form of XHTML, version
4 of the HTML standard. The idea of XHTML is that layout
information is in a different file to the document. If you
want to change the way the document looks, you change the
style sheet, rather than editing the data. Therefore,
style information is a template for any data of a given
format, rather than being copied into every instance of that
kind of data.
The document then is purely a data model of the information,
free of nasty formatting information. The XML design allows
databases and other applications read and write XML data
without being bogged down in formatting information.
VRML has been around for quite a long time, it is a file
format that describes many similar objects to those in
POV. VRML is evolving towards XML. The advantage is that
you no longer need a "VRML parser", you use a generic XML
parser and work with the internal representation of the
data - then write the data back out through a generic XML
emitter.
> I just don't see how it, or a variation of it, would apply to a
> 3D object oriented program such as POV-Ray - not to be confused with
> OO programming.
XML can be used for lots of data-description or
data-modelling problems - including POVray.
Is it not reasonable for POVray to be able to
interface to a database system for complex
scene generation? Or, a visualisation package,
or a CAD system? Or an XML editor with tools for
graphical editing of POV specific information?
An interactive texture editing tool? An
interactive CSG modelling application?
> > For someone with a "povray.org" email address, you are
> > behaving in a very entrenched, "old guard" kind of way.
> When I am speaking in the news groups I do so as myself and not
> representing the views of the POV-Team - which I am not even a
> member of.
Ken, perhaps I came across too strongly, but
given that you started the thread as a point
of discussion, I thought you should be more
neutral. Having a "povray.org" email
address is both a privelege and a responsibility.
There is still a perception of "official
viewpoint" even if it unintended.
Creating a lynch-mob environment will simply
scare programmers away from making any kind
of suggestion. Clearly my perspective is quite
foreign to many POV people, but it doesn't
mean that I am allowed to be as critical of
POV users, as users seem to be critical of any
new or different idea.
> As far as entrenched and old guard let me point out as a POV-Ray
> user who is not only proficient with the program, but also as one
> who is satisfied with it's current language structure, I have every
> right to defend it.
You're not only defending what you're like, but you're
attacking the unknown. These tactics are not fair,
and not productive.
> I think some of the changes being proposed
> jeopardize the ease of use I enjoy with the program
No, they don't.
> One of the key factors that has let POV-Ray
> enjoys it's success and popularity to date is the fact that
> it appeals to such a broad range of people that use if for
> very different reasons. If you lose sight of this you run the
> very real risk of alienating a large portion of it's user base.
No, because I have never suggested removing anything
from POVray that is already there and makes it
desirable to these people.
I keep hearing this threat on the povray newsgroups
of "alienating the user base" - but I don't quite
understand it's basis. We certainly need a better
model of interaction than this polarisation.
As a commercial software developer, I spend all day
pondering the user benefit consequences of software
design decisions. I must admit that I find it
strange to be accused of being an "enemy of the users".
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> > I do not personally like the example you gave and think
> > it unnecessarily makes the scene language harder to use and
> > understand.
>
> I'm working on the assumption that hand-editing is
> not the only way to describe a 3D scene. XML I think
> is editable, but certainly not optimised for this task.
> It is however, far more generic and flexible. XML would
> never be a replacement for POV script, only an alternative.
So if I understand you correctly I will be able to describe my Pov scenes
exactly as I do now without having to use TAGs and all of the other format
styles that come with XML ?
If XML is implemented how will it be incorporated into POV-Ray. Will it
be internal to the program or an external alternative? If external how
will it communicate with POV-Ray ? If POV-Ray has to have two scene
description languages how much baggage will it carry with it ? Is there
any parsing speed advantages with XML ? How much ?
> > > For someone with a "povray.org" email address, you are
> > > behaving in a very entrenched, "old guard" kind of way.
>
> > When I am speaking in the news groups I do so as myself and not
> > representing the views of the POV-Team - which I am not even a
> > member of.
>
> Ken, perhaps I came across too strongly, but
> given that you started the thread as a point
> of discussion, I thought you should be more
> neutral. Having a "povray.org" email
> address is both a privelege and a responsibility.
> There is still a perception of "official
> viewpoint" even if it unintended.
I never attempt to decieve and am careful to be myself. I understand
that there is a certain amount of both privelege and a responsibility
but I also have every right, no every obligation, to speak my own mind.
When I am Mr. TAG or Mr. Linkmaster I sign my messages as such and conduct
myself accordingly. The rest of the time I am going to stay just me.
> Creating a lynch-mob environment will simply
> scare programmers away from making any kind
> of suggestion. Clearly my perspective is quite
> foreign to many POV people, but it doesn't
> mean that I am allowed to be as critical of
> POV users, as users seem to be critical of any
> new or different idea.
I try to be subjective in my criticisms and seldom attempt to encite
a riot. I am also not afraid to speak my mind when I think it is called
for. I certainly don't think that all of our visitors hang on my every
word nor should they. Those who respect me I think do so because they
know me for who I am and not because of my e-mail address. Let's give
the visitors here a little credit for their intellegence.
> > As far as entrenched and old guard let me point out as a POV-Ray
> > user who is not only proficient with the program, but also as one
> > who is satisfied with it's current language structure, I have every
> > right to defend it.
>
> You're not only defending what you're like, but you're
> attacking the unknown. These tactics are not fair,
> and not productive.
The unknown can be a scary place but it's not like I am wearing blinders
either. Sometimes I take the "are you nutz?" stance just to see if I can
get the person making the suggestion to offer a little more clarity about
what they are proposing. We do get some pretty strange suggestions here
on ocassion and you really have to drag the information out of people if
you want to find out what they are really talking about.
> > I think some of the changes being proposed
> > jeopardize the ease of use I enjoy with the program
>
> No, they don't.
If I have to hand code XML then yes they do !
> I keep hearing this threat on the povray newsgroups
> of "alienating the user base" - but I don't quite
> understand it's basis. We certainly need a better
> model of interaction than this polarisation.
What polarization ? With as many people as we have using this
program, for so many differnt reasons, there is no polarazation
present at all. If we (we as in the pov world not ME) change
POV-Ray to support XML to please you, will I, and the other hand
coders be pleased ? Will the modelling programmers such as the
author Moray be pleased with having to recode his entire program
that he has been developing for 6 years supporting the current
syntax ? Will all of the utility writters want to go back and
rework their programs to use the new XML language ? Will I be
able to render all of my older scenes ? Who gets hurt and who
gains ? These are serious questions !
I guess that once I understand the answer to my fisrt question in
this message the sooner I will be able to either support XML or
not. And just because I do not support it does not mean that
others will not. If I decide to personaly not support it then
I will stay out of the way and let others do as they wish with
the idea. If Pov changes, and I don't like it, I'll just quit
using the program. Others may do the same.
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > I'm working on the assumption that hand-editing is
> > not the only way to describe a 3D scene.
>
> So if I understand you correctly I will be able to describe my Pov scenes
> exactly as I do now without having to use TAGs and all of the other format
> styles that come with XML ?
I think that POV script and an XML format should
coexist. Translation from XML to POV script is
easy, going the other way depends on the design
of the POV parser.
> If XML is implemented how will it be incorporated into POV-Ray.
The best way I can think of is to define an API
between the core POV raytracer, which both
the pov script parser and the XML pov parser
can use.
> If POV-Ray has to have two scene
> description languages how much baggage will it carry with it?
Not much, supporting XML is a matter of linking
in a 3rd party libary and some code that interfaces
to the theoretical POV API. In all, a fraction of
the complexity of the current POV script parser.
> Is there any parsing speed advantages with XML ? How much ?
Maybe, maybe not. Hard to say. Interesting question.
> you really have to drag the information out of people if
> you want to find out what they are really talking about.
Ken, I think I've been quite willing to explain
the ideas.
> > > I think some of the changes being proposed
> > > jeopardize the ease of use I enjoy with the program
> If I have to hand code XML then yes they do !
Nobody is going to force you to hand code XML.
To me, this concern is something like a
bycycle owner being worried that if they
get a car - it will be too heavy to pedal.
One of the points of XML is allow
constrained, relevant, accurate and
application specific editing tools.
> What polarization ? With as many people as we have using this
> program, for so many differnt reasons, there is no polarazation
> present at all. If we (we as in the pov world not ME) change
> POV-Ray to support XML to please you, will I, and the other hand
> coders be pleased ?
This is exactly what I'm talking about. You are the
prosecuter, I am the accused. "You are hereby charged
with attempting to subvert the usefulness of the
POVray raytracer..." Why not just discuss the
technical issues without getting emotive?
> Will the modelling programmers such as the
> author Moray be pleased with having to recode his entire program
> that he has been developing for 6 years supporting the current
> syntax?
The Moray author may in fact have their own
opinion, but I expect that if migration is
optional they'd make a decision based on the
usefulness of the feature. I think it would
be very advantagous for the Moray author to
support XML - suddenly their market expands to
include VRML modelling.
> Will all of the utility writters want to go back and
> rework their programs to use the new XML language?
They wouldn't have to, but they might be
seduced by the new possibilities.
> Will I be able to render all of my older scenes?
That is entirely upto the guys who govern
POV script.
XML scenes are much more likely to survive
revisions because conversion can be
automated. (And because, XML is easy to
parse, while POV script isn't)
>These are serious questions !
Yes, and all the questions need to be asked.
> If Pov changes, and I don't like it, I'll just quit
> using the program. Others may do the same.
If POV doesn't change it will certainly
die a slow painful death. Each comment
like this is another nail in the coffin.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> > If Pov changes, and I don't like it, I'll just quit
> > using the program. Others may do the same.
>
> If POV doesn't change it will certainly
> die a slow painful death. Each comment
> like this is another nail in the coffin.
Which is a good reason for me to now keep my comments to myself.
If you do put together a working proposal for the POV-Team let
me know and I will present it to them for you. You can be assured
that I will do so without bias or prejudice and will simply
provide them with whatever material you choose to present.
Other than that there is really not much more I can contribute
to this project because I really am uninformed where XML is
concerned and as such have little to offer in that regard.
Good luck in your endeavors,
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote in message <38D0C535.158EB2F0@nigels.com>...
> I think that POV script and an XML format should
> coexist. Translation from XML to POV script is
> easy, going the other way depends on the design
> of the POV parser.
>
>> If XML is implemented how will it be incorporated into POV-Ray.
>
> The best way I can think of is to define an API
> between the core POV raytracer, which both
> the pov script parser and the XML pov parser
> can use.
Would it be possible to parse and render a mixed format scene, for example,
an XML scene that makes use of existing POV-script include files?
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Would it be possible to parse and render a mixed format scene, for example,
> an XML scene that makes use of existing POV-script include files?
Yes, I think this would be a useful, desirable and
feasible objective. Vice versa as well. It does
imply some shared state information between the
pov-script parser and XML glue to POV, such as
symbol table - but having this in a well defined
module would also be beneficial in other ways.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://www-4.ibm.com/software/developer/library/xml-perl/
Tutorial: XML and scripting languages
Manipulating XML documents with Perl and other scripting languages
Parand Tony Daruger
Co-founder, Binary Evolution, Inc.
February 2000
In this first tutorial of his series on using scripting languages to
manipulate and transform XML documents, Binary Evolution's Parand
Tony Daruger takes you through the first steps of using these
techniques with Perl. You'll see a method for transforming XML
to HTML, followed by a simple stock trading application that uses
Perl, XML, and a database to evaluate trading rules. You can apply
the techniques using other scripting languages too, including Tcl
and Python.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruce,
Thanks for your post, forgive me for not giving it proper
attention, but certainly I'll bite on major points.
> I'm only playing a little bit of Devil's advocate here, and that's
> not meant to derail your concept, but an attempt to understand
> what the benefits are. So on with the games <g>
That's fine.
> Ummm... With the complete source code to the EXACT POV parser
> available,
Which BTW is quite hard to maintain, and can't be incorporated
into a commercial tool because of the POV license. This means
that only POV can read POV files.
> but I suspect your purpose
> is not to be able to quickly make money off the honest efforts of
> other's.
I don't have the attitude that commercial application of open
projects is a bad thing. Linux, X Windows, Gimp or KDE have not
suffered because they've been "ripped off" by companies like
Red Hat, IBM, SGI, etc... In fact, these companies are investing
nice things into the core technology, besides making their money.
My interest here is non-commercial, although I could use it
commercially, if the license was more generous.
At the end of the day, I want funkier tools, not tools that
I own and control. I don't care about owning POV - I wouldn't
even care if I'd invested 1000 hours of my time into it. But
that's me, not the POV team.
> My only comment is "just because it uses the modernized Greek alphabet,
> doesn't make it 'human legible'!
It certainly isn't meant to be hand edited, which is an assumption
that many pov users here have a hard time suspending.
> Ask yourself when the last time was that while reading a
> book you ran across the <aTag> ... </aTag> construct?
Very often actually, but in all the parsers I maintain commercially,
they are formulated in different, inconsistent ways.
> HTML and VRML are horrible languages to parse! They include all sorts of
> forward referencing, allow limitless addition of application-specific
> tags
They are still easier to parse than POV, and are at least standardised
so I can buy a commercial library that can handle the VRML parsing for
me. XML I think is easier to parse because it is more constrained than
HTML or VRML.
>(God forbid you accidentally choose the same 'tag-name' as someone
> else)
This is the whole point of XML. You define the tags that are relevant
to your problem domain, specify this to the XML parser, and the rest
is mainly automatic.
> a large number of other inconsistencies, and are far from being
> 'human legible'!
VRML is far more legible than say, 3ds or lightwave. In some ways
comparibly legible to POV-script, considering the difference
between the architectures.
> So basically, I'm wondering what benefit this would really provide?
A means of properly exchanging 3D data between POV ray, 3rd party
tools, database systems, and your own applications. A standardised
means of encoding POV scenes that can be more easily translated
to later versions of POV. A encoding scheme that is more oriented
to editing tools, because the structure is more explicit.
> I fully endorse the POV-teams wish that POV NOT be a library. It is
> completely user supported, out of the sheer goodness-of-heart of a VERY
> few people, and to turn it into a library would open the door for
> unscrupulous people to use it in their own commercial products.
I respect the right of the POV team to do things this way - but
I honestly think it's time for POV to evolve to a rendering
architecture, rather than a rendering application. It's a two
way street with commercial products, you can't expect anything
back in POV if you shut out the professional 3D graphics
community.
> So. To convert the POV language to make it easier to use for people who
> want to make POV tools, seems like a bit of wasted effort, since the
> language parser is already available in source code.
It's not. It is restricted by licenses, and the interface to
POV is not well defined. I've not heard of anyone using the
existing parser this way.
> but does make the get-rich dweebs look
> for another approach.
?!? Have you had some kind of nasty experience !?!
> I've heard the "This is the newest-greatest-bestest language ever"
Me too, but I think XML is a very interesting and useful technology.
> XML may actually provide useful, but it ain't pretty! And it's a long
> way away from human legible.
It's not even meant for human editing in most cases, but since
POV users are so used to hand editing, it may be too tough a
case to make that other methods may have different strengths
and weaknesses.
> So tell me, what benefit would this actually provide?
There is quite a good list on this thread for you to ponder.
(Hope I don't sound too blunt, I'm in a hurry!)
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 22 Mar 2000 00:58:48 +1100, Nigel Stewart wrote:
>> Ummm... With the complete source code to the EXACT POV parser
>> available,
>
>Which BTW is quite hard to maintain, and can't be incorporated
>into a commercial tool because of the POV license. This means
>that only POV can read POV files.
The POV parser code isn't that hard to maintain. Certainly no harder
than any other recursive-descent parser, perhaps a little easier
than most due to the useful macros.
There's a very well-done POV-to-RIB converter out there somewhere,
using an independently developed parser that happens to be freely
available, I think under the LGPL.
>> My only comment is "just because it uses the modernized Greek alphabet,
>> doesn't make it 'human legible'!
>
>It certainly isn't meant to be hand edited, which is an assumption
>that many pov users here have a hard time suspending.
That's because hand editing (or automatic generation, in some rare cases)
is the only way to make useful scene files. All modelers suck, to one extent
or another.
>> So. To convert the POV language to make it easier to use for people who
>> want to make POV tools, seems like a bit of wasted effort, since the
>> language parser is already available in source code.
>
>It's not. It is restricted by licenses, and the interface to
>POV is not well defined. I've not heard of anyone using the
>existing parser this way.
It is restricted by licenses, but the interface is indeed well-defined. The
definition just happens to be in the form of C source code. But you're right,
nobody is using the existing parser that way, because it's not allowed. Go
reread Chris Young's comments on parsers and the future if you want to know
what the POV-Team thinks should be done about that.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruce wrote:
> Where would I find these comments from Chris Young?
povray.announce.frequently-asked-questions -> plans for 1999 and beyond
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
correction -> plans for 3.1 and beyond
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 21 Mar 2000 12:13:47 -0800, Bruce wrote:
><g> And just for a bit of a teaser, I am looking very seriously at using
>the POV parser in just this way! It means the end product will have to
>be completely open source, and fall squarely within the limitations of
>the POV license, but I hope it will be useful to POV user's, and perhaps
>garner some support and customization from the current user base.
Better check again before you get too far into that...
A "custom version" is defined as a fully functional version of POV-
Ray with all existing features intact. ANY OTHER USE OF ANY POV-
Ray SOURCE CODE IS EXPRESSLY PROHIBITED. The POV-Team does not
license source code for any use outside POV-Ray. No portion of the
POV-Ray source code may be incorporated into another program
unless it is clearly a custom version of POV-Ray that includes all
of the basic functions of POV-Ray.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 21 Mar 2000 12:17:25 -0800, Bruce wrote:
>> It is restricted by licenses, but the interface is indeed well-defined. The
>> definition just happens to be in the form of C source code. But you're right,
>> nobody is using the existing parser that way, because it's not allowed. Go
>> reread Chris Young's comments on parsers and the future if you want to know
>> what the POV-Team thinks should be done about that.
>>
>
>Oh oh. Would it not be allowed if the resulting product was completely
>open source? Perhaps with documentation/licensing information stating
>that it fell under the general POV license?
I'm pretty sure that the only way to get a different set of terms on the
use of the source code is to get specific permission from the POV Team, but
I'm also pretty sure they/we won't give it lightly. You might find that
ParPov, at http://www9.informatik.uni-erlangen.de/~cnvogelg/pov2rib/ , is
a better choice for your project.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruce wrote:
>
> > > Where would I find these comments from Chris Young?
> >
> > povray.announce.frequently-asked-questions -> plans for 1999 and beyond
>
> Well now that's weird. No matter what I do, I can't get netscape to
> display that news group. I'm assuming this is on the news.povray.org
> server? Just as a side comment, I don't notice the OT group either.
> Something stupid I'm doing? I'm using Netscape 3.01, and setting the
> view options to 'display all groups', yet no such animal.
>
> Bruce
I am not sure why that is happening but I assure you the groups exist.
You might try adding the faq group by visiting this page and clicking
on the active link for that group. It might automatically append itself
to your groups list for this server (maybe). We don't have the off-
topic group in that list so this method won't work to add that group.
http://www.povray.org/groups.html
If you want I can foreward that article in question to you.
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruce wrote:
> (Never ceases to amaze me how helpful people are in the POV newsgroups -
> you would think they would tire of providing the same answer after the
> 20 or 30th time <g>)
As Alan Kong is quick to point out on occasion these groups exist
first and foremost to offer customer supprot for users of the program.
I think they do so quite well.
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Which BTW is quite hard to maintain, and can't be incorporated
> > into a commercial tool because of the POV license.
>I've had a quick look through the source, and
> it doesn't really look that hard to maintain
If you don't think so, why don't you go and fix
the bug reported on povray.general under
"Re: POV-file that crashes POV-Ray". It's a
nice tangled one, from what I can see.
> After all, any file format is inherently proprietary
To different extents. One advantage with XML
is that a parser can read any XML file, not
just a particular variant.
> So I'm not sure what the difference here would be. I'm can't see how the
> POV licensing agreement would prohibit you from creating all the POV
> tools you wanted?
The POV license is much more restrictive than GPL or
the BSD license.
> since the people who use
> modeller's couldn't care less what language POV really used.
I think if the modellers suddenly had the choice of
taking their data from Rhino to Autocad to POVray and
then back to Rhino, without any conversion process,
they might regard it as a nice feature.
I think it's weird to claim that users of modelling
packages don't care what format their data is in.
> So why not make a commercial library to parse POV? That would solve your
> problem
No, we are talking about a way that POV can be parsed
_without_ a special POV parser.
> > This is the whole point of XML. You define the tags that are relevant
> > to your problem domain, specify this to the XML parser, and the rest
> > is mainly automatic.
>
> Again, how is this any different than the existing POV parser?
Because the POV parser is hard coded to parse POV, while an
XML parser can be configured to read any XML based format,
without programming.
> they are
> quite willing to provide the parsing libraries for an honest price.
Doesn't solve the problem of tracking each new version
of POV, or automating conversion of old files, or
handling extensions in a transparent way.
> I'm not sure I'm much of a fan of highly explicit structures, since they
> can easily become limiting and loose substantial flexibility.
Not true with XML.
> But POV is first and formost a rendering application.
POV is ONLY a rendering application. There are
good reasons that it should be more flexible.
> I don't see how any professional user's are shut out from using
> POV?
Because I can't use it as a library, POV has zero
commercial interest to me. I'd also want to bypass
the parser and populate the 3D scene from a Inventor
style scene graph, without using files. I'm shut out.
> The licensing agreement is not much different that the GPL licenses for
> Linux etc.
Yes it is.
> And just for a bit of a teaser, I am looking very seriously at using
> the POV parser in just this way! It means the end product will have to
> be completely open source
I don't see the point of doing this, just to get around the
POV license.
> I just have a very high disregard for people who
> think every body else should do all the work, then they should be able
> to recompile it and pocket all the profits.
Perhaps five years ago I could imagine the scenario
(before the Internet) where someone could take POV,
recompile it, put it in a fancy box, and sell it at
the shops.
> Well, pardon me for being so dense, but I can't seem to find them.
> Perhaps you could put togeather a formal list in some kind of point
> form?
The first post to this thread I thought was very detailed.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > You might find that
> > ParPov, at http://www9.informatik.uni-erlangen.de/~cnvogelg/pov2rib/ , is
> > a better choice for your project.
Does anyone know if this supports macros?
It looks quite complete, otherwise.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
>
> > > You might find that
> > > ParPov, at http://www9.informatik.uni-erlangen.de/~cnvogelg/pov2rib/ , is
> > > a better choice for your project.
>
> Does anyone know if this supports macros?
> It looks quite complete, otherwise.
I seem to recall that it is based on POV-Ray v2.2 and even with that
support it is limited to certain subsets of primitives supported by
Pov. I also seem to recall it is buggy and hard to get working.
But this is all hersay until you get someone else to confirm what
I have said.
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 21 Mar 2000 18:03:17 -0800, Ken wrote:
>
>
>Nigel Stewart wrote:
>>
>> > > You might find that
>> > > ParPov, at http://www9.informatik.uni-erlangen.de/~cnvogelg/pov2rib/ , is
>> > > a better choice for your project.
>>
>> Does anyone know if this supports macros?
>> It looks quite complete, otherwise.
>
>I seem to recall that it is based on POV-Ray v2.2 and even with that
>support it is limited to certain subsets of primitives supported by
>Pov. I also seem to recall it is buggy and hard to get working.
It claims support for "version 3" which probably means 3.0, so no macros
or media. I haven't tried too hard to get it working, but the docs do
seem to indicate that it only works with a certain version of some library,
and I seem to recall that PCCTS was a bear to get working.
Great things are happening with upcoming versions of POV, though, so
we shouldn't get too bogged down in all of this. Remember, this is
one of the problems Chris Young said we'd be looking at.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 15 Mar 2000 23:53:21 -0800, Ken <tyl### [at] pacbellnet> wrote:
>> > I think some of the changes being proposed
>> > jeopardize the ease of use I enjoy with the program
>>
>> No, they don't.
>
>If I have to hand code XML then yes they do !
I don't think that Nigel ever encouraged people to hand code in an XML
format. Perhaps you have him confused with me? :)
I started a thread on the IMP mailing lists about that sort of thing,
half-serious and half-joking. Later, I joined the thread you started
here and continued to advocate an XML script style.
Mainly, I wanted to see people's reaction to it, and possibly inspire
some people to think new thoughts. My personal intuition felt the
general idea of mixing POV and XML had some merit, but not being a
programmer, I wasn't sure what the details should be.
Nigel's ideas are definitely more advanced than my suggestions, and I
hope no one confuses what I said with something he said. I certainly
hope that everyone here takes his ideas seriously. I think they have
much merit to them.
Just remember, I was the person that suggested hand coding POV-XML,
not Nigel.
Later,
Glen Berry
IMP Communications Coordinator
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Be sure to read carefully the conditions on how to make and distribute a
custom version of povray.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart <nig### [at] nigelscom> wrote...
>
> The POV license is much more restrictive than GPL or
> the BSD license.
[clip]
> I think if the modellers suddenly had the choice of
> taking their data from Rhino to Autocad to POVray and
> then back to Rhino, without any conversion process,
> they might regard it as a nice feature.
[clip]
> POV is ONLY a rendering application. There are
> good reasons that it should be more flexible.
[clip]
> Because I can't use it as a library, POV has zero
> commercial interest to me. I'd also want to bypass
> the parser and populate the 3D scene from a Inventor
> style scene graph, without using files. I'm shut out.
You bring up very good points. All I can say is that the current license
restrictions on POV were originally intended to protect POV-Ray from
exploitation. Personally, I feel that they are overly restrictive, and POV
can be protected without such strict rules. Of course, I am speaking for
myself and not the POV-Team, but we have begun discussing some of these
issues (in the context of version 4.0).
-Nathan Kopp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 20 Mar 2000 19:09:32 -0800, Bruce <dke### [at] sksympaticoca> wrote:
>To Quote from the same pararaph's:
>"XML is designed to be human legible, and thus mainly text based."
>
>...and to quote from the example a couple pararaph's later:
> <stock_quote>
> <symbol>IBM</symbol>
> <when>
> <date>12/16/1999</date>
> <time>4:40PM</time>
> </when>
> <price type="ask" value="109.1875"/>
> <price type="open" value="108"/>
> <price type="dayhigh" value="109.6875"/>
> <price type="daylow" value="105.75"/>
> <change>+2.1875</change>
> <volume>7050200</volume>
> </stock_quote>
>
>
>My only comment is "just because it uses the modernized Greek alphabet,
>doesn't make it 'human legible'! Although I've been a programmer for a
>...few... years, and I can actually understand it, the term 'barely'
>comes to mind. Ask yourself when the last time was that while reading a
>book you ran across the <aTag> ... </aTag> construct?
I've said this a few times already, but I'll say it again. I'm not
really a programmer. I have written simple BASIC programs in the past.
I've dabbled with machine/assembly language on 6800, 6502, and 8086
compatible microprocessors. More recently, I have written a couple
very simple C language programs. When I look at typical source code
written in C/C++, Perl, or Java, I usually don't a clue what is going
on. These syntax systems seem very alien to me, and nearly
indecipherable. The examples of XML I have seen, are very readable by
comparison.
I think this says a lot. If a non-programmer like me can more easily
interpret XML than the common computer languages in use, it *has* to
be considered human-readable. You claim the word "barely" comes to
mind, but perhaps this is because you have grown so accustomed to
reading another existing computer language. XML *does* look different
than C/C++, Java, etc. You simply have to forget all your
preconceptions of what a language "should look like" to be able to
judge it properly.
>So. To convert the POV language to make it easier to use for people who
>want to make POV tools, seems like a bit of wasted effort, since the
>language parser is already available in source code.
Perhaps you are forgetting that several people have wanted to write a
robust parser for POV in the past, and to my knowledge, no one has.
Apparently, having the POV parser source code available isn't enough
help.
>XML may actually provide useful, but it ain't pretty! And it's a long
>way away from human legible.
I guess it must depend on the human in question. :)
>So tell me, what benefit would this actually provide?
Nigel has already given you a list of advantages. They seemed like
perfectly reasonable and understandable concepts to me. I had also
given some potential advantages myself (Keep in mind, my vision of an
XML implementation was different than Nigel's. I must admit that his
vision of an XML implementation is more interesting.)
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> > So why not make a commercial library to parse POV? That would solve your
> > problem
>
> No, we are talking about a way that POV can be parsed
> _without_ a special POV parser.
>
So, are you talking replacing POV's existing language, or simply
supplementing it? I was under the impression it was the latter,
but if you don't throw away backward compatibility concerns, this
solution will only parse XML format neo-POV files.
Either a POV file can or cannot contain old style code; If it
cannot, that's an end to backward compatibility. If it can, then
what is the generic XML parser going to do when it runs into non-XML
POV code? Ignore it? That's not a total solution and seems vaguely
like writing a parser that only recognizes the keywords added in
MegaPOV, and discards all standard 3.1 code. And #version won't
help, since the generic XML parser doesn't gain POV parsing
capabilities when it encounters a #version directive. You could
write a custom XML parser that also has old style POV parsing
capabilities, but then you've made more work instead of less.
If I understand other discussions around similar subjects, there
has recently been a proposal to create an external API style
language that is preprocessed into standard POV code. Perhaps an
XML style version of this proposal would work better than actually
changing the base SDL of POV-Ray. A scene code in XML style
code would then have all the advantages you indicate without any
of the encumbrance of backward compatibility concerns.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If I understand other discussions around similar subjects, there
> has recently been a proposal to create an external API style
> language that is preprocessed into standard POV code. Perhaps an
> XML style version of this proposal would work better than actually
> changing the base SDL of POV-Ray. A scene code in XML style
> code would then have all the advantages you indicate without any
> of the encumbrance of backward compatibility concerns.
If I understand your post correctly - we're talking about the
same thing in different ways. This is the way I imagine it
unfolding:
1. A clearly defined programmatic API is defined
between POV and the POV-script parser. Something
similar perhaps to the OpenGL API - A basic set
of function calls that can be used to build scenes.
(For the moment, let's ignore political issues
such as the POVteam position of "no API")
2. Definition of an XML based encoding of POV scenes
(perhaps not including loops and macros, to
start with) that can be parsed by an XML parser
and can be glued to the "POV API" without too
much fuss.
3. Support co-existance so that POV-script can
include XML based data and vice versa.
4. Perhaps implement special tags for backwards
compatibility, or supporting any version of
pov script. For example:
<povscript version="3.1">
// Insert your POV script here
</povscript>
or
<povscript version="3.1.megapatch">
// Insert funkier POV script here
</povscript>
I keep having to say the following:
We should keep POV script for it strengths,
ease of hand editing, and general funkyness.
This proposal is not "anti POV script", or
anything like that.
We should look at XML as being a standardised
and extensible scheme that users are not forced
to adapt to. I think that XML can be used
to improve backwards compatibility, rather
than this general reaction of "having to
change/relearn everything".
It may also be interesting to see what the
authors of 3rd party tools think about the
idea. My general concept is that you get the
data in and out in a painless manner, giving
any programmer the facility to manipulate POV
data.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> This proposal is not "anti POV script", or
> anything like that.
Believe me, the following is not intended as an "anti-XML" speech
either, I just feel that incorporating XML parsing into POV-Ray
directly AND maintaining backward compatibility with existing
hand coded SDL will not meet the desired objectives, and I'm
just trying to present a reason why soas not to sound too
irrational for saying it. After this, I'll dutifully wade to
shore and get out of waters too deep for me <G>.
Going back to a couple of points you made...
> 3. Support co-existance so that POV-script can
> include XML based data and vice versa.
Ok, here's where I lose track of the plan. Because a little while
earlier, you said
> No, we are talking about a way that POV can be parsed
> _without_ a special POV parser.
>
The obvious advantage of which is that 3rd party apps wouldn't
have to write a complete POV parser from scratch. But the
extensibility of XML based languages comes from the founding
princible that any code your app won't know what to do with,
just let the parser ignore it. But while I'm impressed that
VRML is trying to evolve in this direction, I've got to wonder
how it's possible because if we do this...
> 4. Perhaps implement special tags for backwards
> compatibility, or supporting any version of
> pov script. For example:
>
> <povscript version="3.1">
> // Insert your POV script here
> </povscript>
Then what, specificly, is the XML parser going to do with the stuff
between the <povscript>...</povscript> tags? If it has no ability
to parse povscript, it has to ignore it. Yet of course it can't
parse povscript, since to incorporate the whole povscript parser
would defeat the original intent.
But in a 3D data file, ignoring part of the scene isn't a valid
option. Consider, for example, if you had SDL hand code that will
programmaticly place 1500 copies of an object using a #while loop.
Dutifully, you wrap it in <povscript> tags, and then set about
trying to import it into a modeller that incorporates an XML
parser. Trouble is, when the scene loads, it's missing 1500
objects because the XML parser had no plan for interpreting the
code in the <povscript> tags. The same is true with 3rd party
extensions to the language that were specially marked so the
parser would ignore them if it didn't recognize them.
In essence what I'm saying is: In order to model, tesselate,
convert, run lparser mutations, do quick render previews, or
anything else useful, the code between the <povscript> tags
must be read and understood by the app, or the result will
be a defective import that degrades the appearace of the scene
in some way. There'd be no problem if XML-POV were a separate
entity (no pun intended) from standard POV script, but there
are hundreds more examples like this and they all revolve
around trying to keep POV SDL (which we both agree is a
good thing) in XML style POV. It simply "loses too much in
the translation."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > <povscript version="3.1">
> > // Insert your POV script here
> > </povscript>
>
> Then what, specificly, is the XML parser going to do with the stuff
> between the <povscript>...</povscript> tags?
>
> ignoring part of the scene isn't a valid option.
Yes it is.
> Trouble is, when the scene loads, it's missing 1500
> objects because the XML parser had no plan for interpreting the
> code in the <povscript> tags.
True, you can't expect to use XML technology to handle non
XML encoding.
> The same is true with 3rd party
> extensions to the language that were specially marked so the
> parser would ignore them if it didn't recognize them.
True, but it still better than choking on 3rd party
extensions. In fact it is probably all that is possible.
> In essence what I'm saying is: In order to model, tesselate,
> convert, run lparser mutations, do quick render previews, or
> anything else useful, the code between the <povscript> tags
> must be read and understood by the app, or the result will
> be a defective import that degrades the appearace of the scene
> in some way.
No. This is merely an option to keep POV purists happy.
Nothing is "taken away" by using XML. Of course you don't
get the advantages of pure XML by mixing it with POV script.
People who want XML functionality have the choice of
avoiding POV script, and vice versa. Mainly, I'd promote
the ability to include old scenes and macro files.
3rd party tools would have to preserve, but igore extensions
and POV script - this is in fact a desirable property, not
a flaw.
The problems you describe here are a good example of why
you probably shouldn't use this feature unless you really
want to, and you know why you're doing it. Whether 3rd
party tools can handle POV script is beyond the scope of
an XML proposal.
To summarise - the problem identified is valid, but I
disagree with your conclusions. I do not think these
features/issues/problems "degrade" the usefulness of
XML at all.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A project to use XML to allow portable exchange of
OpenGL oriented graphical information.
-----------------
XGL File Format Specification
http://www.xglspec.org/
The XGL file format is designed to represent 3D information for the
purpose of visualization. It attempts to capture all of the 3D
information that can be rendered by SGI's OpenGL rendering
library. It uses XML 1.0 syntax, so it is easy to write and
can be parsed by standard, freely available code. These feature
make XGL the ideal format to use when data must be exchanged between
two graphics systems for the purposes of visualization.
The XGL format is intended to work well with systems that use
OpenGL. It should be possible to take a program that renders 3D
information using OpenGL and have that program export an XGL
file. Then, an XGL viewer should be able to create OpenGL
objects that are exactly the same as those rendered by the
exporting program.
Because the XGL format uses XML syntax, it is easy to write
applications that read and write XGL. To export XGL, an
application needs only write out a text file using the XML
syntax. XGL supports a variety of mechanisms for arranging
and referencing data within the file, so it should be easy
to find a method of exporting data that is easy to implement
for any graphics system. There are a number of free XML
parsers available, eliminating the need to implement a
complex parser when building an XGL reader.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Foreword: i'm not sure that the thread still serves something, but what
tf!!
Nigel Stewart wrote:
>
> A project to use XML to allow portable exchange of
> OpenGL oriented graphical information.
>
> -----------------
>
> XGL File Format Specification
> http://www.xglspec.org/
[snip]
What do you actually propose???
that instead of declaring
sphere{
...}
we do:
<primitive
<sphere
Location="12,34,56"
<Texture
<checkered color1=1,.5,1 color2=1,.6,.4>
<transformation>
<rotate 10,0,0>
</tranformation>
>
>
>
(which is pretty structured, compared to what i have seen in web
pages)??
IMHO, it sure is simpler to make a quick parser for it(though , but you
lose much of the possibilities(actually, it becomes more of a hassle)
that using curly brackets to denote which operation is for what part of
the declaration).
BTW, i find that POV's syntax is easier to read(and to parse, if you
take the good way, probably) than XML, BC it was invented to make
human's coders life easier...
BUT, if we didn't have already anything on the table, XML would be a
not-so-bad idea... but how the f*** would u parse the example
above??(Definition language weren't made to support imbricked
things/tags that work only in another tag(see transformation: depending
of its position, it doesn't have the same meaning), imho)
(And, btw, OPenGL is NOT supposed to be human editable...)
LOL, i've got more text in parenthesis than not ;-)
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 30 Mar 2000 21:39:58 -0500, pk wrote:
>[snip]
>What do you actually propose???
>that instead of declaring
>sphere{
>...}
>
>we do:
><primitive
> <sphere
> Location="12,34,56"
> <Texture
> <checkered color1=1,.5,1 color2=1,.6,.4>
> <transformation>
> <rotate 10,0,0>
> </tranformation>
> >
> >
> >
That's not XML. It would look more like
<sphere location="12,34,56" radius="1">
<texture>
<checker>
<color rgb="1,.5,1" />
<color rgb="1,.6,.4" />
</checker>
<rotate><x>10</x></rotate>
</texture>
</sphere>
Note that the distinction between elements and attributes is pretty
arbitrary. When designing a DTD you would have to put some thought into
deciding whether it should be
<sphere location="12,34,56" radius="1" />
or
<sphere>
<location>
<vector>
<x> 12 </x>
<y> 34 </y>
<z> 56 </z>
</vector>
</location>
<radius> 1 </radius>
</sphere>
or something in between.
>(which is pretty structured, compared to what i have seen in web
>pages)??
Most web pages aren't even syntactically correct (Try to point
http://validator.w3.org at some randomly chosen web pages), HTML allows
various shortcuts, and - most importantly - it is meant for marking up
text, not describing a data structure.
>BTW, i find that POV's syntax is easier to read
So do I.
>(and to parse, if you take the good way, probably)
Depends on what mean. A specially coded POV-Script parser is probably
faster at parsing a szene than an XML parser. But writing an XML parser
is easier, and you don't have to do it, because it already exists. (Of
course, at least two povscript parsers exist, too, so this may be a weak
argument).
>Definition language weren't made to support imbricked things/tags that
>work only in another tag
It does. In HTML, for example, a <title> element can only occur inside a
<head> element.
hp
--
_ | Peter J. Holzer \ Vielleicht ist nächstes Jahr der entscheidente
|_|_) | Sysadmin WSR \ Durchbruch in der Bionik, und Microsoft geht
| | | hjp### [at] wsracat \ Pleite und Gardena bringt organische PC's
__/ | http://www.hjp.at/ \ auf den Markt. -- Stefan Schaefer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter J. Holzer wrote:
>
> On Thu, 30 Mar 2000 21:39:58 -0500, pk wrote:
> >[snip]
> >What do you actually propose???
> >that instead of declaring
> >sphere{
> >...}
> >
> >we do:
> ><primitive
> > <sphere
> > Location="12,34,56"
> > <Texture
> > <checkered color1=1,.5,1 color2=1,.6,.4>
> > <transformation>
> > <rotate 10,0,0>
> > </tranformation>
> > >
> > >
> > >
>
> That's not XML. It would look more like
>
> <sphere location="12,34,56" radius="1">
> <texture>
> <checker>
> <color rgb="1,.5,1" />
> <color rgb="1,.6,.4" />
> </checker>
> <rotate><x>10</x></rotate>
> </texture>
> </sphere>
same idea: cumbersome 8)
> Note that the distinction between elements and attributes is pretty
> arbitrary. When designing a DTD you would have to put some thought into
> deciding whether it should be
>
> <sphere location="12,34,56" radius="1" />
there a > and a < missing
>
> or
>
> <sphere>
> <location>
> <vector>
> <x> 12 </x>
> <y> 34 </y>
> <z> 56 </z>
> </vector>
> </location>
> <radius> 1 </radius>
> </sphere>
>
> or something in between.
>
> >(which is pretty structured, compared to what i have seen in web
> >pages)??
>
> Most web pages aren't even syntactically correct (Try to point
> http://validator.w3.org at some randomly chosen web pages), HTML allows
> various shortcuts, and - most importantly - it is meant for marking up
> text, not describing a data structure.
lol...
> >Definition language weren't made to support imbricked things/tags that
> >work only in another tag
>
> It does. In HTML, for example, a <title> element can only occur inside a
> <head> element.
That's not what i meant, sorry...
I meant that there isn't a tag(transformations come to mind) that work
different way depending of the tag in which it's imbricked...
Anyway, i'd be happier if instead of only having predefined shapes, you
could extend the language with an interpreted language ala java, where
there is, say:
Primitive.Class
|
|-cube
|
|-cone
|
|-plane
...
Where the primitive class contains everything you need to define an
object, except the function that defines the object in itself(it parses
everything and calls the good function in the class)
Like, put the result in a public array in the same format the current
rendered uses, and then povray only has to render the everything in the
array...
BTW, i think that unreal script(that's what gave me the idea) is a good
example:
on my miserable(& only computer) 686/133mHZ 24MB ram no 3d card, it can
do more than 5 fps, while interpreting all the weapons that i shoot, all
the movement, all the ai(basically, the only thing that's not
interpreted in unreal is the renderer...) AND rendering the game...
IF you take a look, Unreal script is pretty much like Java, except that
you can decompile everything to its UScript source...
It'd pretty much make almost every patch useless, if you give it the
right capabilities...
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
pk wrote in message <38E666E0.4DD2693B@videotron.ca>...
>BTW, i think that unreal script(that's what gave me the idea) is a good
>example:
>on my miserable(& only computer) 686/133mHZ 24MB ram no 3d card, it can
>do more than 5 fps, while interpreting all the weapons that i shoot, all
>the movement, all the ai(basically, the only thing that's not
>interpreted in unreal is the renderer...) AND rendering the game...
By far the slowest part of the game is the renderer. Everything else
combined takes no more than about 1% of the cpu.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner wrote:
>
> pk wrote in message <38E666E0.4DD2693B@videotron.ca>...
> >BTW, i think that unreal script(that's what gave me the idea) is a good
> >example:
> >on my miserable(& only computer) 686/133mHZ 24MB ram no 3d card, it can
> >do more than 5 fps, while interpreting all the weapons that i shoot, all
> >the movement, all the ai(basically, the only thing that's not
> >interpreted in unreal is the renderer...) AND rendering the game...
>
> By far the slowest part of the game is the renderer. Everything else
> combined takes no more than about 1% of the cpu.
Well, that's the point: Uscript is NOT slow at all(it has to
interpreteverything in the game), and something like it could be used to
invent new operations, tranformation, primitives, etc, and interpret the
classes corresponding to the pov file without slowing down povray
significantly(Maybe that the POV team could ask the creators of
UnrealScript to give them the sources/parts of the source/help... 8)
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 01 Apr 2000 16:15:13 -0500, pk wrote:
>Peter J. Holzer wrote:
>>
>> On Thu, 30 Mar 2000 21:39:58 -0500, pk wrote:
[...]
>> <sphere location="12,34,56" radius="1" />
>there a > and a < missing
No, that line is correct. <tag/> is just an abbreviation of
<tag></tag>. Please see http://www.w3.org/TR/1998/REC-xml-19980210 for
details of the XML syntax.
>> >Definition language weren't made to support imbricked things/tags that
>> >work only in another tag
>>
>> It does. In HTML, for example, a <title> element can only occur inside a
>> <head> element.
>That's not what i meant, sorry...
>I meant that there isn't a tag(transformations come to mind) that work
>different way depending of the tag in which it's imbricked...
Tags don't "work" in XML. They just give structure to a document. The
meaning of the elements is completely up to the application. Besides,
transformations work quite the same regardless of where they are. They
just affect different things.
>Anyway, i'd be happier if instead of only having predefined shapes, you
>could extend the language with an interpreted language ala java, where
Interesting. There are people here who want to get rid of the
programming elements of POV-Script and others who want to turn it into a
full object-oriented programming language :-)
>there is, say:
>Primitive.Class
> |
> |-cube
> |
> |-cone
> |
> |-plane
> ...
>Where the primitive class contains everything you need to define an
>object, except the function that defines the object in itself(it parses
>everything and calls the good function in the class)
I don't see where this gives really an advantage over what you can do
with POV script. You can already define objects of any complexity and
handle them just like the primitive objects.
However, I sometimes miss the possibility do define methods which either
manipulate the object or return information about it. For example, if I
define an object "arm", I would like to write methods to set its
position in different ways (because sometimes I know where the wrist
should be and sometimes I know where the shoulder should be) and to
retrieve the position of the other pieces.
While I can write macros to do this, they are separate from the object,
which makes it difficult to keep them consistent. I think MegaPOV has
some features which make this easier.
hp
PS: Could you please quote only what is relevant to your answers? If my
newsreader didn't color quotes differently than normal text I wouldn't
even have seen that you put in one-line comments between dozens of lines
of my own text.
--
_ | Peter J. Holzer \ Vielleicht ist nächstes Jahr der entscheidente
|_|_) | Sysadmin WSR \ Durchbruch in der Bionik, und Microsoft geht
| | | hjp### [at] wsracat \ Pleite und Gardena bringt organische PC's
__/ | http://www.hjp.at/ \ auf den Markt. -- Stefan Schaefer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter J. Holzer wrote:
>
> On Sat, 01 Apr 2000 16:15:13 -0500, pk wrote:
> >Peter J. Holzer wrote:
> >>
[snip]
> >> On Thu, 30 Mar 2000 21:39:58 -0500, pk wrote:
> >Anyway, i'd be happier if instead of only having predefined shapes, you
> >could extend the language with an interpreted language ala java, where
>
> Interesting. There are people here who want to get rid of the
> programming elements of POV-Script and others who want to turn it into a
> full object-oriented programming language :-)
lol
[snip]
> I don't see where this gives really an advantage over what you can do
> with POV script. You can already define objects of any complexity and
> handle them just like the primitive objects.
If you have just the bare minimum that's not interpreted, it makes
patches useless, and the reason why the pov-ray team will do other
version will NOT be because the community wants another type of light or
something like that, but because they'll want to add capabilities to the
interpreted language, or improve the interpreter ot the raytracer...
And, i think that there's a little misunderstanding: i suggest that
EVERYTHING except the raytracer(which is anyway interpreted by the cpu
8)... That way, you could change the way everything behaves...
an example:
the textured light patch. if the light was interpreted, you could just
use a function that tells you the distance from point 1 at angle x, y, z
until you reach an object, and then change the color of the light at
that angle(a micro sphere around the lightsources with a texture and
filter at 1 would be an easy solution)
> However, I sometimes miss the possibility do define methods which either
> manipulate the object or return information about it. For example, if I
> define an object "arm", I would like to write methods to set its
> position in different ways (because sometimes I know where the wrist
> should be and sometimes I know where the shoulder should be) and to
> retrieve the position of the other pieces.
Or like in this example, you could create a (not so) primitive and use
special statment for transformations... like set the position fo the
hand and of the shoulder, lenght of the arm, etc, and it calculates
everything...
> While I can write macros to do this, they are separate from the object,
> which makes it difficult to keep them consistent. I think MegaPOV has
> some features which make this easier.
Oh, and most of megaPOV could be forgotten, i think... And the argument
that every patch that works shouldn't be included in pov ray 3.5 could
be respected, while letting people use THE combination patch they want
to use...(i think that most of the patches that couldn't be done in the
language are really very important(radiosity could hardly be implemented
in the interpreted language 8)
> PS: Could you please quote only what is relevant to your answers? If my
> newsreader didn't color quotes differently than normal text I wouldn't
> even have seen that you put in one-line comments between dozens of lines
> of my own text.
Note taken 8)
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 03 Apr 2000 22:16:21 -0400, pk wrote:
>And, i think that there's a little misunderstanding: i suggest that
>EVERYTHING except the raytracer(which is anyway interpreted by the cpu
>8)... That way, you could change the way everything behaves...
>an example:
>the textured light patch. if the light was interpreted, you could just
>use a function that tells you the distance from point 1 at angle x, y,
>z until you reach an object, and then change the color of the light at
>that angle(a micro sphere around the lightsources with a texture and
>filter at 1 would be an easy solution)
I'm not familiar with the inner workings of Povray, but I suspect that
the way light works is deep in core of the raytracer. If you implement
this in an interpreted language, you might as well implement the rest of
the raytracer in that language, too.
hp
--
_ | Peter J. Holzer \ Vielleicht ist nächstes Jahr der entscheidente
|_|_) | Sysadmin WSR \ Durchbruch in der Bionik, und Microsoft geht
| | | hjp### [at] wsracat \ Pleite und Gardena bringt organische PC's
__/ | http://www.hjp.at/ \ auf den Markt. -- Stefan Schaefer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter J. Holzer wrote:
>
> On Mon, 03 Apr 2000 22:16:21 -0400, pk wrote:
> >the textured light patch. if the light was interpreted, you could just
> >use a function that tells you the distance from point 1 at angle x, y,
> >z until you reach an object, and then change the color of the light at
> >that angle(a micro sphere around the lightsources with a texture and
> >filter at 1 would be an easy solution)
>
> I'm not familiar with the inner workings of Povray, but I suspect that
> the way light works is deep in core of the raytracer. If you implement
> this in an interpreted language, you might as well implement the rest of
> the raytracer in that language, too.
Actually, each photon isn't interpreted, but the lightsource keyword is,
in this example....
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
pk <thi### [at] videotronca> wrote...
> And, i think that there's a little misunderstanding: i suggest that
> EVERYTHING except the raytracer(which is anyway interpreted by the cpu
> 8)... That way, you could change the way everything behaves...
> an example:
> the textured light patch. if the light was interpreted, you could just
> use a function that tells you the distance from point 1 at angle x, y, z
> until you reach an object, and then change the color of the light at
> that angle(a micro sphere around the lightsources with a texture and
> filter at 1 would be an easy solution)
You could theoretically replace every element of a ray-tracer with
interpreted (by interpreted I/we mean software-interpreted) code. The
question is, "would you want to?" For example, the calculation for the
example that you gave is computed MANY times as a scene is traced. You'd
only want to use an interpreted version if you needed to. On the other
hand, it would be nice to provide the option to use interpreted code if the
desired feature was not implemented in the core functionality. But you
could do this fairly easily without using XML.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote:
> You could theoretically replace every element of a ray-tracer with
> interpreted (by interpreted I/we mean software-interpreted) code. The
> question is, "would you want to?" For example, the calculation for the
> example that you gave is computed MANY times as a scene is traced. You'd
> only want to use an interpreted version if you needed to. On the other
> hand, it would be nice to provide the option to use interpreted code if the
> desired feature was not implemented in the core functionality. But you
> could do this fairly easily without using XML.
I never said that i was for XML Pov 8)
And, the difference between the approach you're proposing and just
interpreting next to 100% of the keywords is that you can change an
already existing keyword, but that's not a big advantage over the
additionnal speed that interpreting only what doesn't already exist
gives you...
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 6 Apr 2000 12:22:56 -0400, Nathan Kopp wrote:
>On the other hand, it would be nice to provide the option to use
>interpreted code if the desired feature was not implemented in the core
>functionality. But you could do this fairly easily without using XML.
Yep, we should have changed the subject. This doesn't have anything to
do with XML any more.
However, if povray was a library, we could link it into pike. Then it
would not only be programmable in pike, java, perl and PHP4, we would
also get XML support, could store the szenes in SQL databases, and have
the first web server with built-in raytracer, too :-)
hp
--
_ | Peter J. Holzer \ Vielleicht ist nächstes Jahr der entscheidente
|_|_) | Sysadmin WSR \ Durchbruch in der Bionik, und Microsoft geht
| | | hjp### [at] wsracat \ Pleite und Gardena bringt organische PC's
__/ | http://www.hjp.at/ \ auf den Markt. -- Stefan Schaefer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
: However, if povray was a library, we could link it into pike. Then it
: would not only be programmable in pike, java, perl and PHP4, we would
: also get XML support, could store the szenes in SQL databases, and have
: the first web server with built-in raytracer, too :-)
Too bad it's expressly prohibited...
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
> : However, if povray was a library, we could link it into pike. Then it
> : would not only be programmable in pike, java, perl and PHP4, we would
> : also get XML support, could store the szenes in SQL databases, and have
> : the first web server with built-in raytracer, too :-)
>
> Too bad it's expressly prohibited...
Well...
It's not "too bad": i really prefer pov the way it is then the way it
could have been if pov was a library ...
(though a library that's freeware ( != gpl) would be ok, i suppose)
Anyway, with OOPov-Ray(better than "A pov-ray that allows defining new
keywirds using OOP 8), someone could do a function tha translates any
kind of file into a pov file...
BTW, is pov.programming a special NG or what? bc this thread has been
going on for more thn 20 days(the longest time i've ever seen a thread
to survive 8)
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > : However, if povray was a library, we could link it into pike.
> > Too bad it's expressly prohibited...
> Well...
> It's not "too bad": i really prefer pov the way it is then the way it
> could have been if pov was a library ...
This doesn't make sense. A POV API would be a different
interface to POV script, and both would be used for
different purposes. A programmatic API takes nothing away
from the POV script interface.
> BTW, is pov.programming a special NG or what? bc this thread has been
> going on for more thn 20 days(the longest time i've ever seen a thread
> to survive 8)
It's a thread that keeps coming back, periodically.
Maybe one day we can tease out of the POV team, the
exact reason for the policy. :-)
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38EE5D72.B098B031@videotron.ca> , pk <thi### [at] videotronca>
wrote:
> BTW, is pov.programming a special NG or what? bc this thread has been
> going on for more thn 20 days(the longest time i've ever seen a thread
> to survive 8)
Messages in the POV-Ray newsgroups, except in povray.off-topic do not expire
as long as server harddisk space permits.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart <nig### [at] nigelscom> wrote...
>
> It's a thread that keeps coming back, periodically.
> Maybe one day we can tease out of the POV team, the
> exact reason for the policy. :-)
>
As I understand it, the reason for the "no libraries" policy is to protect
POV-Ray from commercial exploitation. It may be possible to protect POV
without this limitation, but that will have to be discussed further before
any major changes are made.
-Nathan
(I speak for myself, not for the POV-Team.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
